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Abstract 

The Java programming language contains many features that 
aid component-based software development (CBSD), such 
as interfaces, visibility levels, and strong support for en- 
capsulation. However, component evolution often causes 
so-called breaking changes, largely because of the rigid- 
ity of component interconnections in the form of explicit 
method calls and field accesses. We present a Java extension. 
Poplar, which we are currently developing. In Poplar, inter- 
component dependencies are expressed using declarative 
queries; concrete linking code, generated using a planning 
algorithm, replaces these at compile time. Poplar includes a 
minimal specification language based on typestate-like pro- 
tocols and labels, and a lightweight effect system, which 
ensures the absence of unwanted interference between hand- 
written code and generated code. We give several examples 
of fully automatic component integration using Poplar, and 
demonstrate its potential to simplify object-oriented soft- 
ware development greatly through evolvable and statically 
checkable integration links. 

Categories and Subject Descriptors D3.3 [Programming 
Lan^Magei]: Frameworks; D3.3 [Programming Languages]: 
Constraints 

General Terms Languages 

Keywords CBSD, protocols, programming languages, code 
synthesis, typestate, object-oriented programming, planning, 
adaptation, evolution 

1. Introduction 

Two essential and related properties of object-oriented pro- 
gramming languages hke Java are encapsulation and poly- 



[Copyright notice will appear here once 'preprint' option is removed.] 



morphism. Encapsulation is the principle of separating in- 
terface from implementation, and this in turn enables poly- 
morphism, whereby the runtime type of an object may be 
different from its declared type in the source code, and 
thus unknown to the caller. When two classes have the 
same interfaces, according to the principle of behavioural 
subtyping[18J, the implementations should be substitutable 
for each other and all expected safety properties should 
be retained. Contemporary programming paradigms such 
as component-based software development (CBSD) [Z, ,27| 
draw heavily on these principles. 

Theoretically, interfaces of classes should only change 
in backward-compatible ways once they have been pub- 
lished, for instance through the addition of new methods, 
or through the widening of assumed preconditions and nar- 
rowing of assumed postconditions. Interface changes that 
require client classes to update their associated client code 
are called breaking changes. While developers strive not to 
make such breaking changes, it has been found that in prac- 
tice they are commonplace ISj. Breaking changes introduce 
a large cost into component-based software development, 
since potentially every dependent class may have to be up- 
dated. In other words, CBSD, as it is practised today, suffers 
from a conflict between software evolution and flexibility of 
composition. The more likely a class is to evolve, the greater 
the potential future cost of having included it in a software 
system. Moreover, the need for class evolution is unlikely to 
go away, since few software specifications are final. Classes 
may receive new features, changes in the domain that they 
model may necessitate an implementation change, bugs may 
be fixed, and so on. 

Tentatively, we can identify certain categories of language- 
level breaking changes that can occur in modern imperative 
object-oriented languages, such as Java, C# and C++. 

Name changes. The renaming of a method, everything else 
being the same. 

Protocol changes. Often, a sequence of method invocations 
is required to establish a certain effect or compute a cer- 
tain value. When this sequence changes from one class 
version to another, we say that a protocol change has 
occurred. This includes permutations of protocol steps, 
but also addition of new steps and removal of old steps. 
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Values may pass between method invocations in a proto- 
col fragment in a complex way; changes in these inter- 
method dependencies with respect to a result should also 
be considered to be protocol changes. 

Type changes. Methods may be moved from one class to 
another; argument and return types may be changed to 
incompatible types. 

Signature changes. The number of arguments that methods 
require may change, without visibly affecting the func- 
tionality that existing clients receive. 

In addition, there are changes that occur above the level 
of the language, such as conceptual semantic changes and 
quality attributes |4|. 

Considering these problems, we believe - as did Shaw |f 25l 
in 1993 - that traditional class interfaces, consisting of col- 
lections of named methods and their signatures, lead to a 
very rigid form of class interconnections, which permit little 
evolutionary flexibility. Current interfaces expose inessential 
information, such as method names and argument ordering, 
that clients become dependent on, while at the same time 
not exposing essential information, such as semantics, valid 
class protocols and valid interactions, that clients need in 
order to construct and verify integrating links. We are cur- 
rently developing a Java extension. Poplar, which attempts 
to reinvent component integration to address these prob- 
lems. Poplar adds several concepts to the Java language to 
support a new kind of composition methodology, in which 
integration requests are expressed using declarative queries. 
At compile time, we generate concrete linking code, whose 
content will reflect factors such as what components are 
available and how they have evolved. 

We face several essential problems that need to be ad- 
dressed in order to make this approach work. 

Complexity of code synthesis Code synthesis is generally 
a difficult problem. Whole-program synthesis is gener- 
ally successful only for small examples, and even then is 
often very computationally expensive, due to the use of 
a theorem prover or a constraint solver ifTSi l20l . Gener- 
ally, a lot of this complexity stems from the use of a rich 
description language, such as Hoare logic or OCL. We 
beUeve that, since we are not attempting whole-program 
synthesis, our description language should be simplified 
as much as possible in order to reduce the complexity 
of the synthesis problem. Our first design principle is to 
use a minimal description language. In designing this, we 
draw on the idea of typestate protocols [7 , 26], which is 
a natural way of constraining and describing API usage 
in a useful, compact and evolvable manner. We also use 
atomic, uninterpreted labels, which have been used pre- 
viously in the context of ML lfTOl . 

Effects and interference Since Java expressions may have 
side effects, it becomes necessary to reason about poten- 



tial interference caused by these in some way. In gen- 
eral, we will be generating short Java code fragments that 
are to be inserted at the location of integration queries 
in client code, and thus mixed with hand-written code. 
For each generated statement, it is essential to know 
whether it may interfere with other generated statements, 
or with the pre-existing hand-written statements. In order 
to model this, we use a simple effect system based on ab- 
stract resources, which are an adaptation of Boyland and 
Greenhouse's abstract regions 19|. 

Aliasing Third, in order to reason on side effects on a per- 
object basis, we will need some way of constraining 
aliasing, since in Java, each object may potentially have 
any number of references. For this, we use a minimal 
uniqueness system |23|, where references and method 
arguments are classified according to what assumptions 
they make about references, and whether they may create 
any aliases. 

In choosing what effect system and aliasing policy to 
use, the rationale has been to use minimal concepts that 
are easy to understand and discuss, in order to allow us 
to design a framework with relatively clear functional and 
validity properties. However, future improvements to the 
accuracy of the effect system or the aUasing policy should 
be independently possible without great impact to the overall 
design. Our framework also does not impose any particular 
constraint on what algorithm or algorithms to use in the 
generation of solutions, but a natural choice is Partial Order 
Planning (POP) |21|, which has shown promise in a very 
early prototype that we have tested. 

Our design permits both modular integration and modular 
checking of integrations. 

We make the following contributions. 

• We introduce Poplar, a Java extension that provides a 
framework for declarative specification of integration 
queries, automated code generation for their satisfaction, 
and effect protection. 

• We outline how the POP algorithm can be used to gener- 
ate solutions to integration queries in our framework. 

The rest of the paper gradually explains and illustrates 
features of Poplar using examples. We introduce the basic 
ideas of labels, queries and solutions (Section l2]i, followed 
by type protocols and abstract resources (Sectionjsll. In Sec- 
tion |4] we describe how effects may be protected using un- 
shared references and effect spans. We introduce a realistic 
example based on the Swing GUI toolkit in Section [5] and 
show how subclasses may extend and override resources, 
protocols and annotations from superclasses. We also intro- 
duce interclass protocols, which describe how classes can 
interact in useful ways. In Section |6] we discuss the details 
of code generation using POP. We show how Poplar can be 
adopted and used in practice, as well as discuss its limita- 
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interface TimeAndDate { 

labels(int) nowHour , nowMinute, nowSecond; 

} 

class Date implements TimeAndDate { 
labels currentTime; 
Date () 

result: +currentTime ; 
int GetHourO 

this : currentTime , 
result : + nowHour ; 
/* Similar annotations for getMinute(), 
getSecondO, etc. */ 

} 



Figure 1. TimeAndDate annotations for Java 1.4. 

tions in Section [7] Finally, we discuss related work (Sec- 
tion |8]l and conclude the paper (Section |9]l. 

Throughout this paper, we disregard issues raised by con- 
currency or reflection. We discuss a possible approach to ex- 
ceptions in Section|9] 

2. A basic example 

We introduce the Poplar Java integration mechanism using a 
simple example from the real world. The time and date API 
of the standard Java libraries changed substantially between 
version 1.4 and version 1.5 of the language. In version 1.4, 
the following code was used to obtain the current hour of the 
day: 

Date now = new Date(); 
int hour = now . getHour () ; 

In Java 1 .5 and later versions, the following code is used: 

Calendar now = Calendar . getCalendar () ; 
int hour = now . get (Calendar . HOUR_OF_DAY) ; 

Even though the Java 1.5 libraries keep the old version of 
the API, this is representative of a breaking change that may 
occur in practice, and API pubUshers generally prefer not to 
have to preserve old versions. 

In principle. Poplar considers integration sites to have one 
of two possible purposes: producing values or producing ef- 
fects. In these two cases we use produce queries and trans- 
form queries, respectively. Clearly, in this case, a client com- 
ponent that wants to use the time and date API wants to do 
the former Before we can request the production of a value, 
we must annotate the API that is provided by the service 
component. In the case of Java 1 .4, the component supplier 
should provide annotations similar to the ones in Figure [T] 

2.1 Labels 

We have added the labels annotation as a new mem- 
ber of classes and interfaces. In the case of the interface 
TimeAndDate, labels are provided for the int type using 
the notation labels(int). Once these labels have been 
defined, we can logically distinguish between integers that 
have these labels and integers that do not, as a lightweight 



refinement of the type system. Since the Date class imple- 
ments TimeAndDate, references to nowHour in this class are 
understood to refer to the label defined in the TimeAndDate 
interface, but it is possible for other interfaces to define la- 
bels with the same name, and their meaning might be differ- 
ent. Disambiguation should be done in the usual way using 
fully qualified names where necessary. 

In the Date class we have added pre- and postcon- 
ditions to the methods. The constructor Date() declares 
that the result, ie the return value, will have the new label 
currentTime. This label was declared in the Date class 
itself. The + sign indicates that a new label is added. In con- 
trast, the getHour method indicates that for the this variable, 
the receiver of the method, an invariant of the currentTime 
label is expected - the label must be owned by the this ob- 
ject prior to method invocation, and it will remain after the 
invocation. When this method is invoked, the return value 
will be an integer which has the nowHour label. Here, the 
labels describe one kind of useful application of the method, 
but not mandatory constraints on it. It is still valid to in- 
voke this method when the this variable does not have the 
currentTime label, but in this case, unless the annotations 
are augmented beyond what is shown here, we can make no 
assumptions about the return value. As for the client com- 
ponent which wants to produce the value corresponding to 
the current hour of the day, its code should resemble the 
following: 

class TimeUtils implements TimeAndDate { 
void printHourO { 

int hour = #produce ( i n t , nowHour); 
System . out . println ( "The current hour is: " + 
hour) ; 

} 

} 

Again, we use the TimeAndDate interface to refer to the 
nowHour label. We request a production of an integer value 
with this label using the #produce query. We prefix queries 
with a '#' sign to distinguish them from normal Java code. 
At compile time, the Poplar solver will find a solution to 
this query and replace it with a sequence of Java statements. 
Such statements can be field accesses or method invocations, 
including constructor invocations. In principle, queries may 
be inserted anywhere that a sequence of statements may 
occur in Java. Code resulting from queries may return a 
single value, and the queries may thus be "assigned" to a 
variable, as in the example we have just shown. 

The solver uses a planning algorithm to find a solution to 
the query. The plan search will proceed backwards from the 
goal to the assumptions. In this case, the goal is the existence 
of a variable of type int and with label nowHour. First the 
planner needs to find all actions that can produce such a vari- 
able (method invocations and field accesses). If the only one 
available is the one we declared above (Date . getHour), then 
once this method has been selected, a new set of precondi- 
tions will result - in order for that method to be invoked, we 



3 



2013/1/28 



Class Calendar implements TimeAndDate { 
labels(int) hourMarker , m i nu t eMa rke r , 

secondMarker; 
labels def aultTimeZone ; 

final int HOUR_OF_DAY +hourMarker = 11; 
/* etc. */ 

Calendar () 

result: +def aultTimeZone { ... } 
int get(int selector) 

this: defaultTimeZone , 

(selector: hourMarker, 

result: +nowHour)?, 

(selector: minuteMarker , 

result: +nowMinute)? { ... } 

} 

Figure 2. TimeAndDate annotations for Java 1.5. Here the 
+ sign indicates an invariant. 

need to have a Date object with the currentTime label. We 
repeat the search and find that there is a constructor that takes 
no arguments and that produces such an object. This yields 
a complete solution, and thus, after the code has been gener- 
ated and the substitution has taken place, the client class will 
look like the following: 

class TimeUtils implements TimeAndDate { 
void printHourO { 

Date v1 = new Date () ; 
int hour = v1.getHour(); 

System . out . println ("The current hour is: " + 
hour) ; 

} 

} 

In addition, the solver will remove non-Java elements 
from the code, such as the label declarations from the various 
classes, so that the result is valid Java source code. 

2.2 Upgrading to Java 1.5 

Let us now consider how we could adapt this client to the 
Java 1 .5 version. In this case, the service component would 
resemble the one shown in Figure |2] 

In this case, all the values are accessed through one 
method, which takes a selector argument. We have given 
the field HOUR_OF_DAY an explicit label hourMarker, which 
links it to its possible use as an argument for the get(int) 
method. We group invariants and postconditions using the 
(a, b, . . . )? syntax, which makes the pre- and postcon- 
ditions inside the group optional. This is mainly a syntactic 
shorthand to avoid having to repeat the defaultTimeZone 
requirement for the this object. In this case, however, clearly 
minuteMarker, hourMarker and so on will be mutually ex- 
clusive labels. The plan search now takes the same query as 
a starting point, but the APIs supplied as input are different 
(and perhaps the 1.5 API is marked as taking precedence 
over the 1.4 one if both are available) and after substituting 
a solution for the query we end up with: 



new DateO 




/\ 





new CalendarO Calendar.HOUR_OF_DAY 



(Date, currentTime) 



XT 



getHourO 



7T 




(int, nowHour) 



(int, nowHour) j 



Finish 



Figure 3. Visual representations of the plans generated in 
the case of producing the current hour of the day in Java 1.4 
and 1.5, respectively. 



class TimeUtils implements TimeAndDate { 
void printHourO { 

Date v1 = new CalendarO; 

int v2 = Calendar . HOUR_OF_DAY ; 

int hour = v1.get(v2); 

System . out . println ( "The current hour is: " + 
hour) ; 

} 

} 

We show the plans visually in Figure |3] The resulting 
code is extracted directly from the plans. Rounded boxes are 
pre- and postconditions (the existence of a variable with a 
given label), and square boxes are actions such as method 
invocation and field access. Dashed lines represent sequen- 
tial constraints, which impose an ordering on the actions. 
These constraints will be at least as strong as the dataflow 
dependencies of the solution, and possibly stronger due to 
possible conflicts. 

These examples demonstrate how clients can automati- 
cally be reconfigured to use a new version of an API, or 
even a different API, given that the necessary annotations 
are present on both the client and the service side. In this 
case it would simply be a matter of re-running the integra- 
tion tool with the newest service components added to the 
classpath. 
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qualified res. 
label decl. 

uniqueness 

method def. 

method decl. 
method arg. 
mut. summary 
conjunction 
condition 
invariant 
effect 

external decl. 
expression 

query 



X variable, T type, C class, / field, I label, r resource, m 
method, p protocol, s protocol state, je Java expression 

Figure 4. Syntax of Poplar Elements that are unchanged 
from standard Java have been omitted. A horizontal bar 5; 
indicates repetition. 

2.3 Syntax 

We give the syntax of Poplar in Figure |4] We have omitted 
many inessential features, including constructors, imports 
and the interface forms of method declarations, as well as 
elements that are unchanged from standard Java, for brevity. 

3. Protocols, resources and protection 

Having explained basic synthesis based on labelled vari- 
ables, we will now introduce the additional features of type 
protocols, abstract resources and effect protection. These 
features are intended to provide a basic level of safety and 
guarantee that generated code does not interfere with itself 
or with handwritten code. 

3.1 Type protocols 

Type protocols is a version of the technique known as type- 
state checking ll26l . In typestate checking for objects Q, 
every class is considered to possess a formal protocol de- 
scribed by a state machine, which regulates valid and invalid 
message sequences for that class. In Poplar, we do not check 
that existing code conforms to typestate protocols, but use 



class Socket { 
protocols type; 
Socket 

result: +type@raw {...} 
void Bind ( SocketAddress bindPoint) 



endPoint) 

} 



this: typeSraw ->bound {.. 
void connect ( SocketAddress 

this: type@bound ->open {. 
void Send(byte[] data) 

this: type@open {...} 
int rece ive ( byte [] data , int offset, int max) 

this: type@open {...} 
void closeO 

this: typeOopen ->closed {...} 



Figure 5. A socket class. Note the type@a— >b protocol an- 
notations. 

these protocols as a generative constraint. We simply never 
generate any code that violates any declared typestate proto- 
cols. 

A network socket is a natural example. Sockets go 
through a well defined sequence of method calls during 
their lifetime: they cannot open a connection before they 
are bound, and they cannot send or receive data until they 
have been opened. When they have been closed they can no 
longer send or receive data. A partial socket class is shown 
in Figure |5] An annotation like type@raw — > bound speci- 
fies that the this object must be in the type@raw state prior to 
the method invocation, and will be in type@bound after the 
invocation. The benefit of this is that, for instance, if we re- 
quest the production of an open socket from scratch, it must 
necessarily pass through all the intermediate steps first. We 
permit multiple protocols with different names in each class. 

3.2 Abstract resources 

Sometimes it is desirable to partially constrain the behaviour 
of a class, when its state can be naturally partitioned into dis- 
tinct areas or modes of operation. For instance, a GUI widget 
that contains other widgets could have its state separated ac- 
cording to appearance and contents. In the case of the socket, 
we can separate its state according to the state of the con- 
nection and the data being sent. We do this using the syntax 
shown in Figure |6] 

Here we have declared two abstract resources, connState 
and data. Like labels and protocols, they can be declared in 
any classes or interfaces. A resource is a stateful asset of 
any kind, which may include Java fields and data accessed 
using JNI including external data such as sockets and graph- 
ics. Resources may be mutated, which logically means that 
some kind of change has occurred. An annotation such as 
[ ! connState] simply means that the connState resource 
is mutated if the corresponding method is invoked. Thus, 
another way of thinking about abstract resources is that they 
are a group of methods which may mutate a single property 
in some way. A resource r is defined by the set of [ ! r] an- 
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class Socket { 
protocols type ; 
resources connState , data; 
Socket () 

result: +type@raw {...} 
void bind ( Socke tAddress bindPoint) 

[! connState] 

this: type@raw ->bound [*connState] {...} 
void connect ( SocketAddress endPoint) 
[! connState] 

this: type@bound ->open [*connState] {...} 
void send(byte[] data) [!data] 

this: type@open {...} 
int receive (byte [] data, int offset, int max) 
[! data] 

this: typeSopen {...} 
closeO [IconnState] 

this: type@open ->closed {...} 

} 

Figure 6. The socket class with resource mutations ( [ ! x] ) 
and residence ([*x]) included. 

notations in the class that declares it. The exact nature of the 
resources is not identified beyond annotating the methods 
that may affect them. In this way, they differ from Boyland 
and Greenhouse's 15] abstract regions, which are similar to 
our resources, but that describe groupings of Java fields only, 
and thus cannot manage external state. 

In addition to methods mutating abstract resources, achieved 
effects can reside in them. This declares that the effect 
will last for as long as the resource is not mutated. Thus, 
for instance, the notation [*connState] of the connect() 
method indicates that the effect of transforming the state 
typeSbound into typeSopen resides in the connState re- 
source. The opened socket will remain in type@open as long 
as this resource is not mutated. An effect may reside in any 
number of resources. 

3.3 Protection spans 

The benefit of this kind of annotation is to constrain the 
generated code further by indicating resources that are to be 
protected. For instance, consider the network server shown 
in Figure [7] In this case, we are concerned about the socket 
being closed prematurely by mistake, and we would like to 
protect ourselves against this kind of mistake, whether from 
hand-written or generated code. 

The server repeatedly reads requests from the socket 
and processes them. Depending on the exact request, the 
readRequestO method, as well as the code generated in 
the #produce(ClientRequest , processed) query, may 
dispatch the request to various different code locations, of 
which new ones may potentially be added in the future - 
for example through polymorphism or through regeneration 
of the query's solution. Assuming that the produce query 
is resolved using the Socket . open() method given in Fig- 
ure |6] we know that the effect type. open should reside in 
the resource s. connState, and thus it can be protected by 



void se rveCl i en t ( . . . ) { 

Socket s = #produce (Socket , type. open) 
{ //Protection span begins here 
boolean quit = false; 
do { 

string r = readRequest (s) ; 

ClientRequest cr = #produce (ClientRequest , 

processed ) 
quit = shouldQuit (cr) ; 
} while (quit == false); 
} //Protection span ends here 
ttransf orm (s , type . closed ) ; 

} 

Figure 7. A simple network server Note the protection 
span, which is denoted by { } signs, and emphasised by 
comments. Generated and hand-written code inside the span 
must not violate the protection rule. 

ensuring that this resource is not mutated. In Figure|7j we use 
standard curly braces to indicate the start and end of a protec- 
tion span. Handwritten code inside the span is checked, and 
generated code is constrained for compliance. At the point 
of the #transform(s , closed) query, the protection span 
has ended, and the socket can be closed in a valid manner. 
Depending on the precise way that the #produce (Socket, 
type . open) query is satisfied, the protection span will have 
a different meaning, so if protection fails during code gener- 
ation, the code generator may be spurred to attempt finding 
a different solution with more lenient or different resource 
protection needs. Note that a #transform query is different 
from a #produce query - the former requests that a label be 
added to an existing value; the latter requests the production 
of a new value. 

In addition to abstract resources belonging to instance 
variables, we may also define static abstract resources that 
correspond to invocation of static methods, similar to the 
approach taken in . 

Reasoning about side effects like this requires two new 
language elements that have not been introduced so far: 
uniqueness kinds and mutation summaries. We will discuss 
them in the following section. 

4. Mutation summaries and uniqueness 
4.1 Mutation summaries 

In order to protect resource such as connState in Figure |7] 
we will need a way of gathering all the potential mutations 
that can occur as a result of invoking a method. We choose to 
annotate methods with mutation summaries, in the style of 
Boyland and Greenhouse's effect summaries f9l. They sim- 
ply summarise all the potential (recursive) effects of invok- 
ing a method. Assume the network socket introduced earlier, 
and consider the following utility method. 

void connectAndSend (maintain Socket s, 
SocketAddress sa , byte[] data) 
mutates s. connState, s.data: { 
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s . connect ( sa ) ; 
s . s e n d ( d a t a ) ; 



} 



In this case, since the s. connect and s.send methods 
mutate the s.connState and s.data resources, we have 
Usted them in the mutation summary. 

Mutation summaries are simply Hsts of resources, proto- 



cols and managed fields (Section 4.2 1 that may be mutated 



by a method. Every method that may be used for code gen- 
eration, and also every hand-written method that may have 
to be checked inside a protection span, will need to be anno- 
tated with a mutation summary. Also, every method that is 
called by a method with a mutation summary must also have 
a mutation summary. We discuss the effort associated with 



annotating methods in Section 7.4 



Mutation summaries can be checked by using local infor- 
mation only. We discuss the burden of creating annotations 
in Section |7.4| There will be cases when developers may 
want to declare additional mutations beyond what is imme- 
diate in the method, in order to allow subclasses to perform 
these mutations safely, a point that we will return to in Sec- 
tion |5] 

4.2 Managed fields 

In addition to mutations of arguments and receivers, muta- 
tion summaries may include mutations of fields. In the case 
of object (reference) fields, except strings, this should be on 
the basis of what resources have been mutated. In the case 
of primitive or string fields, we consider them to be mutated 
if an assignment occurs. 

Class designers may partition the fields of a class into 
managed fields and unmanaged ones. Fields are unmanaged 
by default. Managed fields must occur in mutation sum- 
maries whenever they are mutated. They are available, to- 
gether with method arguments and newly created objects, 
for use by the planner as part of solutions, and they can be 
protected by protection spans, since we can track what mu- 
tations may occur on them. Unmanaged fields are handled 
entirely by the programmer and cannot be protected or used 
in planning. This gives the class designer an encapsulation 
mechanism, by which the concrete implementation of an ab- 
stract resource can be represented as a set of unmanaged 
fields, which are then guaranteed to be left alone and un- 
interfered with by subsequent planning attempts. Managed 
fields are assigned to an abstract resource using the syn- 
tax managed (r). We give an example in figure |8] The re- 
source records is implemented using the fields data and 
lastRecord. Because they are unmanaged, generated code 
will not refer to them directly, but they can be accessed 
through the methods addRecord and getLastRecord. Sub- 
classes can redefine the records resource freely, for instance 
using a LinkedList instead. The field policy is managed, 
and is the subject of a query in the setlnverseSorting 
method. Every method that mutates the policy field must 
now report this, and we are also able to protect its resources. 



class Recordset { 
Record[] data; 
int lastRecord; 

labels (Record) toAdd , added, lastRecord; 
resources records, recordPolicy ; 
managed ( reco rdPol i cy ) unique Sor t i ngPol i cy 
policy; 

//(initialisers and other code omitted) 

void addRecord (Record r) mutates records: 
r : toAdd , +added { 
data [ lastRecord ] = r; 
las tRecord ++ ; 
sort () ; 

} 

Record getLastRecord () 
result: +lastRecord { 
return data [ lastRecord ] ; 

} 

void se 1 1 n ve r seSor t i ng ( ) 
//Alternative: mutates policy 

mutates recordPolicy: { 

#transform(policy , inversePolicy) 

} 

} 

Figure 8. A record set that tracks some number of records, 
with a configurable sorting policy. Note that the policy 
field is managed, which means that methods must report 
mutations to it, that it can be protected, and that it can be 
used as part of query solutions. Unique indicates that the 
field is strictly unique (Section |4~4li. 



There are two ways to report the mutation of a field 
such as policy in Figure |8] If we indicate that a resource 
of the owning class is mutated, as done in the figure, we 
allow overriding classes to potentially place new fields in 
the resource and mutate them. If we indicate specific fields 
and their resources, we restrict subclasses' overriding abil- 
ity, but we have more precise information about the method 
locally, which may allow internal code generation to suc- 
ceed in some cases where it otherwise would have failed. If 
mutations of specific private/protected/package fields are de- 
clared, they are automatically converted to the correspond- 
ing resource from the point of view of outside classes that 
cannot see the field. 

As for communication between managed and unmanaged 
parts of a class, several policies are possible. We suggest the 
use of "accessor methods" for use in code generation that 
read or write unmanaged fields and describe the returned 
data or the achieved effects in terms of labels and resources. 
An example of this is the addRecord and getLastRecord 
methods in Figure [8] 
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4.3 Mutation summaries and queries 

From the example in Figure[8]a question arises: what should 
happen if the solution to the query in setlnverseSorting 
requires more mutations than what is allowed by the muta- 
tion summary? In this case, the method specifies that only 
the field policy may be mutated. One design possibility 
would be to never allow solutions to exceed protection sum- 
maries. Another would be to generate code freely and then 
rewrite the mutation summaries as necessary. In this latter 
case, the generation of one solution might trigger a cascade 
of necessary regenerations across a code base, which seems 
undesirable. We expect that in practice, developers will have 
some summaries they are willing to change and some that 
they are not (for instance, internal data such as private fields 
should be much more plastic), and therefore, a Poplar imple- 
mentation should be configurable as to what summaries may 
be rewritten and which ones should be respected when code 
is generated. 

4.4 Uniqueness 

In order to apply mutation summaries to the checking of a 
protection span, it is necessary to reason about aliasing of 
variables. Consider the following example. 

void m(Socket si, Socket s2) { 
#transf orm (si , type. open) { 
// ... 
s2 . close () ; 
// ... 

} 

} 

The intention here is to open the socket si and keep it 
open until the end of the method. In the middle of the span, 
s2 is closed. Clearly, if si and s2 could be the same object, 
s2 . close() is invalid. This statement can only be permitted 
if we can know for certain that they cannot be the same. We 
should conservatively assume that two sockets may be the 
same if there is any doubt. 

Many sophisticated schemes for reasoning about alias- 
ing have been investigated; many of them revolve around 
some kind of uniqueness or ownership property. Evaluating 
sophisticated approaches to be used with Poplar is beyond 
the scope of this paper, and here we will settle for a simple 
uniqueness system. The idea exists in various forms in liter- 
ature, see for instance |23|. Since it is slightly crude, it may 
constrain the plan search process, but it should be easy to see 
the intention behind its design and validity. We will annotate 
references, including method arguments and return values, 
with the following uniqueness kinds. 

Normal is a reference without any constraints. It permits 
any number of existing aliases, and any number of aliases 
may be created in the future. References are normal by 
default. 



Maintain indicates that the method does not create any 
aliases of the argument. However, a value being passed 
in may already have existing aliases. 

Maintain retains , or maintainr for short, indicates that 
the method may create a single new alias using a "de- 
structive read". In other words, the caller cannot retain a 
reference to an argument that has been passed in this way, 
but must nullify it. 

Unique is a refinement of maintain. No new aliases may be 
created, and the value must have no preexisting aliases. 

Unique retains , or uniquer for short, is a refinement of 
maintain retains and of unique. The value must have no 
aliases, and at most a single new alias may be created. 

In addition to method arguments, these also apply to 
return values. For newly created objects, unless otherwise 
specified, we may select a uniqueness kind to attribute to 
them. The idea with this system is that the number of aliases 
of an object cannot increase as a result of passing it to some 
method as one of the maintain or unique argument kinds. In 
addition, receivers of unique arguments can assume that the 
incoming values are definitely unshared. 

Now consider the example given above again. If si is 
unique or uniquer, then clearly s2 cannot be an alias of si, 
so the s2 . close statement is permitted. If s2 is unique or 
uniquer, then the same is true, so in this case too, s2 . close 
is permitted. If neither is unique or uniquer, the statement 
cannot be permitted. 

We mentioned destructive reads as a means of transfer- 
ring references. An example would be as follows. 

void setX (maintainr Object x) { 
this . X = X ; 

} 

void doSet () { 

Object X = new SpecialX(); //Assuming unshared 

and permission to assign 
setX (x) ; 

X = null; //Reference destroyed after being 
passed on 

} 

However, it is not always necessary to nullify references 
like this after using them in a destructive read. For variables 
that expire at the end of the method, like this one, it is 
sufficient to never access them again (at least not in a way 
that may have side effects or create additional aliases). 

Note that even for a maintain or unique argument or 
return value, we permit the creation of dynamic aliases as 
part of method invocation or returning a value. For instance, 
the code shown in Figure[9]is valid. 

These argument and field annotations can easily be veri- 
fied syntactically by inspecting local code only. Overriding 
methods must have compatible uniqueness flags for their ar- 
guments and return values. We show permitted overriding 
for argument kinds and return values in Figure [TO] as well as 
permitted reference flow. 
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class Container { 

unique Object x; //definitely not aliased, no 

aliases may be created 
maintain Object getX() { //unique may flow to 

maintain 

return x; //caller is not permitted to create 
a heap alias 

} 

} 

// . . . 

int computeHash (Container c) { 

Object X = c.getXO; //creates an alias, but 

only locally 
return x . hashCode () ; 

} 

Figure 9. Dynamic aliases may be created for the sake of 
invoking methods and receiving a return value. The rules of 
unique and maintain references apply to static aliases only, 
i.e. the ones that are stored in the heap. 



Reference flow and return value overriding 




Figure 10. Top: Permitted argument flow and return value 

overriding of uniqueness kinds. For instance, a value re- 
ceived as uniquer can be passed as a maintainr argu- 
ment if a destructive read (DR) takes place. Every kind can 
be passed to itself, with DR as necessary. Bottom: Permit- 
ted overriding of argument kinds. Maintain arguments may 
override unique arguments, and so on. Both of these rela- 
tions are transitive. 



We now consider how to apply the uniqueness kinds to 

mutation summaries. Consider again the previous example: 

void connectAndSend (maintain Socket s, 
SocketAddress sa , byte[] data): 
mutates s.connState, s.data: { 
s . connect ( sa ) ; 
s . send (data ) ; 

} 

If the argument s had been normal instead of maintain, 
the summary would instead have been: 
mutates any (Socket) . connState , any ( Socket ). data 

This is because we cannot know which object will be 
mutated in the case of a normal reference. Recall that it is 
also permitted to pass a normal reference in the place of 
a maintain argument, for instance in the connectAndSend 
method given above. In this case, we also have to upgrade 
the mutation summary so that it is considered to mutate 
these keys on any object, instead of just on s. When we 
generate code this kind of transformation should be carried 
out automatically. 

4.5 Checldng protection spans 

When we check the safety of a protection span, we inspect 
the mutation summary of every statement inside the span, 
making use of aliasing constraints and summaries as follows. 
A variable-resource pair is associated with each span. If the 
variable that is protected is unique, then it is unshared, and 
clearly the protected resource is safe unless that variable is 
passed directly as an argument in such a way that this re- 
source will be violated, according to the summary of the in- 
voked method. If the variable is not unique, then we must 
avoid mutations of the form any(T) . r, where T is a type to 
which the protected variable is assignable, and r is a sen- 
sitive resource. If we have access to other variables than the 
protected one, of a compatible type, and that are unique, then 
we are allowed to violate the sensitive resources on those 
variables, since they can still not be aliases of the protected 
variable. We aid this scheme by tracking the potential alias- 
ing state of new variables as we pass them to methods, keep- 
ing them maximally unshared when we generate code. 

5. Interclass protocols, subclassing and 

resource linking 
5.1 Subclassing 

Generally, class elements in an inheritance-polymorphic lan- 
guage such as Java must abide by the substitution principle, 
that is, we must be able to substitute any concrete subclass 
for a declared class type without any loss of safety properties 
or expected functional properties of the program. The vari- 
ous Poplar elements are affected in different ways by this 
requirement. 

• Subclassing must weaken preconditions or leave them 
unchanged, or strengthen postconditions or leave them 
unchanged. 
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• Mutations must be the same or lesser, and established 
effects (set up using the [*x] notation), in so far as they 
were declared on the superclass level, must be set up in 
the same resources or in smaller or fewer ones. 

• Protocols in subclasses must be subprotocols of the over- 
ridden protocols. 

• Uniqueness kinds of method arguments and return values 
should be overridden in an acceptable way. The applica- 
ble constraints are given in Figure [10] 

• New abstract resources may be added in subclasses as 
subresources of akeady defined resources. 

• Existing abstract resources may be completely redefined 
by subclasses - the behaviour of their member methods 
may change, in terms of how they affect unmanaged 
fields - since their definition is never exposed. 

• Subclasses may define new managed fields and add them 
to existing or new abstract resources. Subclasses can- 
not remove managed fields from resources they have al- 
ready been added to, and they cannot associate preexist- 
ing fields with preexisting resources. 

5.2 A Swing example 

We introduce the remaining features of Poplar using an ex- 
ample based on the Swing GUI toolkit. In this example, 
we will construct a GUI library supporting efficient appli- 
cation development. The central classes will be SmartFrame 
and SmartWidget. When SmartWidgets are installed in the 
SmartFrame, they supply a Swing component to be dis- 
played, as well as commands that operate on it, which need 
to be made accessible to the user through the GUI. Depend- 
ing on the concrete subclass of SmartFrame, the commands 
may need to be displayed in different ways. 

First, we introduce the SmartWidget and Command classes 
(we have omitted visibility levels and some boilerplate code 
for brevity): 

class SmartWidget { 
/* ... */ 

List <Command > getCommands() { ... } 
JComponent getComponent () £ ... } 

} 



class Command { 
/* ... */ 

String getTitle () { ... } 
int getMnemon i c () { ... } ^ 
} 

Then, the SmartFrame is as shown in Figure [TT] 
We have defined three resources for the SmartFrame: 
appearance, widgets, and commands. Appearance is de- 
fined as setupO and show(), widgets is defined as installWidget(), 
and commands is defined as installCommand() and 
installCommands(). Note that the frame field can be ob- 
tained using getFrame(). The link to the appearance re- 
source will be automatically inferred, and any external 



abstract class SmartFrame { 

resources appearance, widgets, commands; 
managed ( appea ra nee ) unique JFrame frame = new 
JFrame () ; 

ma naged ( appea ra nee ) unique JPanel panel = new 

JPanel(new BorderLayout () ) ; 
List <SmartWidge t > widgetList = new ArrayList< 

SmartWidget >() ; 

SmartFrameO { setup(); } 

//We anticipate that subclasses may want to 

mutate panel 
void setupO [! appearance] mutates frame. 

appearance . size , frame . contents , panel: { 
frame .setSize(500,500); 
frame . add (panel ) ; 

} 

void installWidget (maintainr SmartWidget w) [! 
widgets] mutates panel . contents , commands, 
widgetList: { 
panel, add (w. getComponent () , BorderLayout. 
CENTER) ; 

installCommands(w.getCommands()); 
widgetList . add (w) ; 

} 

abstract void installCommand (Command c) [! 
commands ] ; 

void installCommands (maintain List<Command > 

commands) [! commands] 
mutates widgetList: { 
for (Command c: commands) { 

installCommand (c) ; 

} 

} 

void show() [! appea ranee ] mutates frame. 

appearance { f rame . se tV i s i ble ( t r ue ) ; } 

//We automatically infer that the return value 

is linked to this . appearance 
unique JFrame getFrame() { 
return frame; 

} 



Figure 11. The SmartFrame class. 
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class MenuFrame extends SmartFrame { 

managed ( appea r a nee ) unique JMenuBar menuBar; 
managed ( appea r a nee ) unique JMenu menu; 
void setupO [! Appearance] mutates menuBar. 

contents, menu . contents , frame . contents : { 

super . setup () ; 

menuBar = new JMenuBar(); 

menu = new JMenu (" Commands ") ; 

menuBar . add(menu) ; 

frame . setJMenuBar(menuBar) ; 

} 

void installCommand (Command e) [! commands] 
mutates menu . contents : { 
//All code in this method can be replaced by 

the following query: 
// #produce (Object , i n s t al 1 ed I nGUI ) 

JMenuItem item = new JMenu I t em ( c . ge tT i t le () ) ; 
item. setMnemonic(c. getMnemonicO) ; 
item. addAetionListener(c) ; 
menu . add ( item) ; 

} 

} 

Figure 12. The MenuFrame class. 

classes that obtain it will be aware, from a code genera- 
tion point of view, that mutating it would also mutate the 
SmartFrame appearance resource. 

From the setup () method we can also discern that 
JFrame declares aresource called JFrame . appearance . size, 
and a resource called JFrame . contents. This kind of 
subresource mutation propagates upward, also mutating 
frame, appearance and the universal root resource frame, root. 
SetupO also declares that it mutates the panel object, even 
though the method body does not access it. This declara- 
tion is added in anticipation of subclasses that may need to 
mutate it. 

We have added the strictest possible uniqueness flags to 
fields and method arguments. We do not add any particular 
flags to the argument of installCommand (Command), since 
implementations will need to create several aliases. 

5.3 Concrete subclasses 

We now introduce a concrete subclass of SmartFrame, 
MenuFrame. Its source code is given in Figure [T2| 

MenuFrame redefines and extends the original appearance 
and command resources with additional concrete state. Here, 
the overriding setup () method is allowed to mutate re- 
sources of menuBar and menu, even though this was not de- 
clared at the original setupO method in SmartFrame. This 
is only acceptable because menuBar and menu are newly 
defined in this class, and because they are strictly unique. 
If they had not been strictly unique, each setupO method 
up to the level of SmartFrame would necessarily have had 
to expose mutations such as any(MenuBar) . contents. This 
requirement could possibly be lifted with a more sophisti- 
cated uniqueness/ownership analysis. Because menuBar and 



class ToolbarFrame extends SmartFrame { 

managed ( appearance ) unique JToolBar toolBar; 
void setupO [! appearance] mutates panel, 
contents : { 
super . setup () ; 
toolBar = new JToolBar(); 

panel.add(toolBar, BorderLayout. PAGE_START) ; 

} 

void i n s tal ICommand ( Comma nd e) [Icommands] 

mutates toolBar . contents : { 
//All code in this method can be replaced by 

the following query: 
// #produce (Object , i n s t a 1 1 ed I nGUI ) 

JButton b = new JBu t ton ( c . ge tTi t le ( ) ) ; 
b. setMnemonic(c. getMnemonicO) ; 
toolBar . add (b) ; 
b. addActionListener(c) ; 

} 

} 



Figure 13. The ToolbarFrame class. 



menu are reported in summaries, they are considered to be 
managed, and thus we are able to protect effects on them. 

The other concrete subclass of SmartFrame is ToolbarFrame. 
It is given in Figure [T3] 

ToolbarFrame mutates panel. contents, which is al- 
lowed since the original SmartFrame . setup() anticipated 
this. This subclass, too, has extended the definitions of both 
the commands and the appearance resources. Again, mutat- 
ing toolBar . contents is acceptable in installCommandO 
since toolBar is unique and declared in this class. 

5.4 Interclass protocols 

Let us now consider how we can use Poplar to generate code 
for the task carried out by installCommand in each of the 
two concrete classes. Both the toolbar case and the menu bar 
case require interaction between classes to fulfil their func- 
tionality: JButton and JToolBar in the former, JMenuItem 
and JMenu in the latter. For such cases. Poplar provides in- 
terclass protocols, which describe how different classes may 
meaningfully interact. For the toolbar and the menu bar case, 
we may provide two different protocols which have some 
definitions in common, as shown in Figure [T4| 

In this case, the protocols have been added inside the 
Command class, although in principle they could reside in 
any interface. A best practice should be to place interclass 
protocols inside the most specific classes that participate in 
them (i.e. the most dependent), when such a distinction can 
be made. The numerical state specification (1 — > 2 etc.) is a 
convenient shorthand when the intermediate states have no 
useful meaning, and thus no natural names. 

Note that we are defining protocols that involve exter- 
nal classes (JButton and JMenuItem, respectively). The 
two protocols have the same name (addAction) but can- 
not be interleaved or mixed up, since the state transi- 
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class Command { 

labels(int) actionMnemonic ; 
labels ( St ring) actionTitle; 
labels(JButton , JMenuItem) installedlnGUI ; 
protocols (JButton , JMenuItem) addAction; 

int getMnemonic () 

result: actionMnemonic {...} 
String getTitleO 

result: actionTitle {...} 

external JButton (String title) 

title : actionTitle , 

result: +addAction@1 ; 
external JButton . setMnemonic ( int mnemonic) 

mnemonic:actionMnemonic, 

this : addAction@1 ->2 
external JToolBar . add (JButton b) 

b: addAction@2 ->3 
external JButton. addActionListener( 
ActionListener al) 

this: addAction@3 ->4 , +installedInGUI 

external JMenuItem(String title) 

title : actionTitle , 

result: +addAction@1 ; 
external JMenuItem . setMnemonic (int mnemonic) 

mnemonic: actionMnemonic, 

this : addActionSI ->2 
external JMenuItem. addActionListener( 
ActionListener al) 

this: addAction@2 ->3 , 
external JMenu . add ( JMen u I t em mi) 

mi: addAction@3 ->4 , +installedInGUI 

} 

Figure 14. Enhanced Command class with interclass proto- 
cols. The installedlnGUI label can be queried for to pro- 
duce an effect involving multiple interacting classes. 



tions occur on different types. We provide the "goal label" 
installedlnGUI for both of the two types. 

Also note that these "external" annotations caimotbe used 
on their own. They are overlaid with the corresponding an- 
notations for these methods inside the JToolBar and JMenu- 
Item classes, so that mutations and other constraints can be 
taken into account. For external annotations to be valid, they 
have to be combined with a non-external annotation for the 
same method. 

Given these protocols, in place of the four statements in 
ToolbarFrame. installCommand, we could use the follow- 
ing query: 

void installCommand (Command c) [! commands] 
mutates toolBar . contents : { 
#produce (Ob ject , installedlnGUI) 

} 

The exact same query would also work inside Men- 
uFrame.installCommand, and produce different solutions in 
the two cases. With this change, the supplier of the Com- 
mand class may change the definition of the fully Added 



label freely in the future, perhaps providing alternative ways 
to achieve it or changing the algorithm shghtly, requiring 
other inputs. Also, the code expresses more precisely what 
the programmer's intention is. 

6. Planning and code generation 

The design of Poplar does not restrict the choice of planning 
or search algorithm that is to be used for the code generation, 
but in early experiments on a prototype, we have found 
Partial Order Planning (POP) to be a useful algorithm. We 
now discuss how POP can be applied to finding Poplar 
solutions. 

POP gradually refines a partial ordering of some set of 
actions. In principle, it searches the space of all possible 
plans, instead of searching the space of all possible states, 
as many planners do. POP is a good fit for the problem ad- 
dressed here, because 1) Java statements are already in some 
sense partially ordered, through dataflow dependencies for 
instance, and 2) POP is relatively easy to understand and in- 
fluence, and it should be a good fit for situations where some 
amount of human interaction may be needed, for instance 
in tweaking annotations, disambiguating between values and 
so on. The basic idea of the POP algorithm is that it gradu- 
ally strengthens an ordering of actions, inserting causal links 
(connecting post- and preconditions of related actions) and 
new actions as necessary while maintaining a set of open 
preconditions. Conditions will be either of the form new(T, 
1), indicating a new variable of a given type and label, or 
label (x, 1), indicating that a variable has a certain label. 

A backward search from the goal towards the initial con- 
dition is performed as follows. 

• Step 1 . Initialise the plan to have two pseudo-actions start 
and finish. The effects of the start action are identical 
to the assumed envirormient of the plan, i.e. the starting 
conditions. The preconditions of the finish action are 
identical to the goals of the plan. 

• Step 2. If there are no open preconditions, stop. A solu- 
tion has been found. 

• Step 3. Select an open precondition in the current plan. 

• Step 4. For all available actions that achieve the precon- 
dition and are either already in the plan or not in the plan, 
create a successor plan with this action added. Also add 
ordering constraints and causality links (which pair pre- 
conditions with postconditions) for the new action. 

• Step 5. For all the successors, resolve any conflicts 
among the causahty links that might have arisen by 
strengthening the ordering constraints. If this is not pos- 
sible, discard the successor. 

• Step 6. Recurse on each successor plan. Go to step 2. 

In addition to the plan itself, the planner needs to keep track 
of the following mappings: 
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• The planning context, which is the set of all variables that 
are available to the planner at any given point. Inside a 
method body, it is initialised to contain the arguments of 
the method, managed fields, and all local variables that 
have been initialised prior to the query expression. 

• type(a;), which maps each variable in C to its type and 
uniqueness flag. 

• labels(a;), which maps each variable in C to its label set. 

• resources(.T, /), which maps a variable and label pair to 
the set of abstract resources of that variable which the 
label may reside in. 

• uniqueness(a;): the uniqueness kind of each variable. 

6.1 Variable reuse and progress 

When the planning algorithm needs to fulfil a precondition, 
before attempting to construct a new value, it first looks 
among the known existing values, to see if any of them 
fits the requirement. We consider two variables with the 
same type and the same labels to be equivalent, and if one 
has labels that are a superset of the labels of another, but 
the types are equal, then the variable with fewer labels is 
redundant. If 

type(x) <: type(y) A labels(a;) D labels(y) 

where <: denotes subtyping, then generally, x can take 
the place of y. 

More precisely, a new variable is useful if it has at least 
one of the following: 

1 . A new type which was not previously available for use 

2. A new type/label combination which was not previously 
available for use 

3. A stronger uniqueness flag than what was previously 
available for some type/label combination. 

4. An effect that resides in a smaUer set of resources, or a 
new set of resources, for some type/label combination. 

From this view we obtain the important ability to tell 
when a plan search is making no further progress. Given 
a finite number of actions, and a finite number of labels 
(which will always be the case), we gradually make progress 
from having produced nothing to having produced all possi- 
ble useful values. Furthermore, if we remember the state of 
the plan after each search step, we can also identify when the 
search is cyclically creating and destroying the same condi- 
tions, making no progress. So the plan search is decidable, 
although in practice we wiU want heuristics to avoid the fuU 
exploration of this very large search space. 

6.2 Heuristics 

The POP algorithm needs at least two heuristics: one for 
selecting the next open precondition to plan for, and one 



for selecting the most appropriate action to attempt for a 
given precondition, in the event that several are available. 
Designing appropriate heuristics is in the scope of future 
work. In our early prototype, we have attempted to use the 
following naive precondition heuristic with some success: 

• If a precondition has no available actions, select it (in 
order to fail quickly and backtrack). 

• If a precondition has only one available action, select it. 

• Otherwise, select the precondition with the smallest 
amount of available actions, in an attempt to lock in nec- 
essary decisions early and reduce the size of the search 
space. 

For the action heuristic, we have experimented with 
schemes that favour syntactic locahty when selecting ac- 
tions. For example, prefer fields in the same class over in- 
voking a method, prefer local methods over methods in other 
classes, and prefer classes in the same package over classes 
in other package. 

6.3 Forced inclusion 

In the installedlnGUI example in the previous section, 
there are two ways to produce the desired effect. One makes 
use of classes such as JMenuItem and JMenuBar, the other 
makes use of JButton and JToolBar. As long as the planner 
gives all possibilities the same amount of search effort, it 
should find the appropriate solution in each of the two chent 
classes. However, there may be situations when one wants 
to force a particular solution or influence the planner to do 
something that does not correspond to the "best fit" in a 
particular context. For this, we introduce the with syntax, 
so that one can write a query such as the following. 

#produce (Object , installedlnGUI) with JMenuItem 

This kind of modifier is the dual of a protection span. Pro- 
tection spans identify resources that are not to be used, and 
with-clauses identify classes or labels that must be used as 
part of the solution, and get the highest priority in case of 
ambiguity. This may help reassure programmers who are 
naturally hesitant to use tools that generate code which may 
vary from time to time. 

7. Discussion and practical concerns 

7.1 Verifying upgrades 

When published classes change, their interfaces are re- 
pubUshed if protocols or method annotations have changed. 
Checking whether an existing integration is still valid is then 
a matter of checking whether the new annotations are com- 
patible with the old ones. The Poplar code generation tool 
should output a set of integration assumptions for each query 
that it solves. They would capture the full signature of each 
method or field assumed in each plan, and be stored together 
with the Java class files. For a future upgrade to be com- 
patible without code regeneration, we would compare future 
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method and field signatures with what is stored in the as- 
sumptions; every step should comply with the same rules as 
for subclassing (see Section|5]l. 

Using such integration assumptions, when we check the 
validity of an existing integration, we may also be able to 
identify minimal parts of the existing integration plans that 
are invalid, and reconstruct only those, leaving the remaining 
parts of the integration intact. 

7.2 Applicability and limitations 

In the introduction, we mentioned several kinds of breaking 
changes that may occur in Java source code, including syn- 
tactic changes, protocol changes, semantic changes, and so 
on. We believe that Poplar would be able to address many of 
these issues automatically. 

An important limitation of Poplar is that control flow con- 
structs are not generated. For instance, we do not generate 
loops or if-statements. This means that when flow control is 
required, as in the case of an iterator which needs to repeat- 
edly test a truth condition in a loop, this information should 
be communicated externally. For an iterator, separate queries 
could be used for the truth condition and for the loop body. 

Poplar assumes, in #produce queries, that the type of the 
desired value is known. The more specific this type is, the 
easier the query will be to resolve. However, this may also 
couple the client strongly to a particular implementation, in 
the case where the same functionality is supplied by different 
components that have no shared type hierarchy. 

Exceptions have not been considered in this paper Ex- 
ception handlers can play a role similar to protection spans, 
effectively constraining the methods that can be considered 
for use in solutions, but further work is needed to clarify the 
details. 

7.3 Reliability and predictability 

Developers that use Poplar might be concerned about the fact 
that generated code can vary from time to time. Our basic 
means of ensuring sensible outcomes of code generation are 
as follows. Firstly, variables with the same type and labels 
must be truly equivalent. If they are not substitutable for each 
other, more labels should be added to disambiguate. Second, 
protection spans should be used to protect those resources 
that may not be mutated. In the case of handwritten code that 
surrounds queries, developers may need to identify resources 
that need to be protected manually. 

The outcome of a code generation attempt is dictated 
by the choices of algorithm and heuristics. In general, we 
think that a good algorithm should strive to favour short 
valid solutions over longer valid solutions, once other needs 
have been taken into account. Thus, one situation that may 
lead to unexpected outcomes is if a component supplier 
makes it easier than before to produce a given type/label 
type, thereby making the altered protocol a simpler means 
of production than existing protocols. In this case, at the 
next regeneration, the shortened code fragment may out- 



compete some existing solutions in the quest to be shortest, 
which could have adverse consequences if annotations are 
not precise enough. 

The with modifier, which forces the inclusion of an ele- 
ment in a plan, as well as the ability to decide which vari- 
ables are managed (available for planning) and unmanaged 
should be valuable countermeasures towards unwanted out- 
comes. 

7.4 Adoptability 

In adopting Poplar for use in an existing Java code base, it is 
necessary to add annotations concerning mutations, unique- 
ness, protocols, resources and so on. We have seen that in- 
formation such as mutation summaries and uniqueness can 
easily be inferred locally on a class by class basis, and such 
an inference tool should be simple to make. In addition, if 
one sets up a temporary mapping between unmanaged fields 
and abstract resources in a class (to be discarded afterwards), 
it should be easy to infer a partial set of resource definitions 
([ ! x] annotations). It is even possible to infer protocols, as 
in |fT9l . In addition, when Poplar is introduced into an ex- 
isting code base, it should be possible to start with a small 
number of queries and annotations, and gradually expand the 
use of Poplar within the code base. 

8. Related work 

8.1 General 

The notion of component-based software was discussed as 
early as 1965 in a study by Mcllroy [22J. 

Shaw |25 1 carried out one of the first studies that highlight 
the brittleness of procedure call based component intercon- 
nections in 1993. 

Aspect-oriented programming fTSl (AOP) weaves to- 
gether code from different aspects and inserts them, at com- 
pile time, in locations that are specified declaratively. The 
acceptance of AOP indicates that developers are willing to 
use tools that generate extra code at compile time, provided 
that they can easily understand what will result. 

One of the first descriptions of the partial order planning 
algorithm was given by AUister and Rosenblatt 11211 . 

8.2 Code synthesis 

Two of the most fundamental approaches to code synthesis 
are deductive EOl and inductive llT2l synthesis. 

Haack [lOl has created a system that unifies software 
components in the ML language by generating code from 
uninterpreted, atomic annotations, much like Poplar. How- 
ever, given the differences between ML and Java, and that 
ML unification is the central technique in Haack's work, it 
is not clear if the findings can be applied to an imperative 
object-oriented setting. 

Bastani et al. |3| describe glue code synthesis for embed- 
ded systems based on code patterns. A code pattern is a code 
fragment with pre- and postconditions expressed in OCL, 
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and thus it is not integrated with the programming language. 
Synthesis is carried out by composing code patterns accord- 
ing to predefined rules when possible. The system is depen- 
dent on a general theorem prover. 

Ireland and Stark i 11 j have designed a system that com- 
bines proof plans and partial order planning to generate 
small imperative programs. The examples given are math- 
ematical routines specified using Hoare logic for pre- and 
postconditions. The heuristics and proof critics used here 
are adopted from the literature on Structured Programming, 
which describes principles that are to be used for manual 
goal-directed programming. This should be a valuable av- 
enue for future investigation of heuristics for Poplar 

Jha, Gulwani et al. [131 have described a system that 
synthesises loop-free imperative programs from components 
using an SMT constraint solver. However, "components" 
here are not in the CBSD sense, but rather, they are algorithm 
fragments. The specification language used is fine grained, 
and the computational power is spent on a much more fine 
grained level than in Poplar 

8.3 Evolution and adaptation 

Dig m has carried out an empirical study of in component 
evolution. Strikingly, he found that between 81% and 100% 
of all breaking changes in several large systems were due to 
refactorings. Vasa et al [281 studied the evolution of several 
large Java libraries in terms of the proportion of derived 
types and the distribution of classes into various layers of the 
architecture. They find that in quantitative terms, interfaces 
do not grow very much over time. However, in light of the 
findings from |8l, it is likely that many subtle changes that 
their quantitative approach cannot capture have occurred, 
such as protocol changes and semantic changes. 

Zaremski and Wing f29] have studied component discov- 
ery and matching. They classify several kinds of matching 
relations, including plug-in matches, exact matches, matches 
with slightly weaker or stronger specifications than the query 
given, and so on. It is possible that their classification of dif- 
ferent matches could be applied in a future Poplar integration 
algorithm. 

Becker et al ||4l discuss an engineering approach to adap- 
tation. They give a taxonomy of possible component mis- 
matches, ranging from signatures, assertions and protocols 
to quality attributes and semantic concepts. They also dis- 
cuss the use of design patterns to overcome these mis- 
matches. Design patterns can provide good leverage in terms 
of reducing the problems introduced by evolution, but cannot 
remove such problems since they are bound by the program- 
ming language. 

Kell |fT4l n?! focuses on adaptation on a binary, operat- 
ing system level (shared objects in Unix). He identifies two 
myths about component based software development: that 
there is a notion of a "matching module" that can be discov- 
ered and plugged in, and that development of components 
occurs in order: depended-on first, dependent later. 



8.4 Java effect systems 

Boyland and Greenhouse |9 1 describe an effect system based 
on abstract regions, which are very similar to the abstract 
resources used in Poplar. However, the abstract regions are 
sets of concrete fields, instead of being sets of methods, and 
the intention is to capture reads and writes, rather than muta- 
tion and residence, as in our case. They also introduced the 
idea of effect summaries based on the abstract regions. By 
generalising beyond field reading and writing, focussing in- 
stead on method invocations. Poplar can define resources as 
corresponding to practically any effects that can be achieved 
with Java code, including effects achieved with native meth- 
ods. Boyland and Greenhouse's analysis was later adapted 
to Middleweight Java - a core imperative fragment of Java - 
by Parkinson et al [61, and this version was formally proven 
to be correct. Data groups, by Leino et al 1 17 1 are a slightly 
simpler idea that predates abstract regions. 

Pearce |24| has introduced a modular purity system for 
Java. It makes judgments based on the locality and freshness 
of variables. Unlike in Poplar, where effects are identified 
in terms of abstract resources, Pearce's system identifies the 
absence of observable heap (field) writes. 



8.5 Typestate cliecking 

Typestate was first introduced by Strom and Yemini ll26l 
as an approach to checking valid interactions with primitive 
types and simple data structures. 

Define and Fahndrich Q describe how typestate check- 
ing can be applied to object-oriented languages. They use a 
core subset of C# as an example. A key concept in their sys- 
tem. Fugue, is the notion of sliding methods: subclasses may 
refine the meaning of state transitions, and every overrid- 
ing method may implement a slightly stronger state change. 
A sliding method first invokes its corresponding superclass 
method before implementing its own part of a change. Bier- 
hoff et al. |5 | describe a modular approach to typestate 
checking that is based on linear logic for interface descrip- 
tions. This enables them to track the multiplicity of outstand- 
ing references, for instance the number of iterators that have 
been produced from a collection. Their approach allows pro- 
tocols to have subprotocols, which has similarities with re- 
sources and subresources used in Poplar. 

Aldrich et al. |[T] have described typestate oriented pro- 
gramming, an effort that is being realised in their program- 
ming language Plaid. Plaid integrates typestate as a first class 
language construct; however it is used strictly for checking 
and safety constraints, and not as an integration aid. 

Mandelin et al. (191 describe a tool that mines typestate- 
like protocols from code bases presumed to be valid, some- 
thing that could be useful in generating initial Poplar anno- 
tations. Their work was an important inspiration for Poplar. 
However, the tool is designed for interactive use only, and 
does not reason about side effects or aliasing. Poplar aims to 



15 



2013/1/28 



support fully automated integration and verification of inte- 
grations at compile time. 

9. Conclusion and future work 

We have presented Poplar, a Java extension designed for au- 
tomated component integration based on queries and code 
generation. Through the use of abstract resources, protocol 
and label annotations, aliasing constraints and a planning al- 
gorithm. Poplar enables controlled generation of integrating 
code with constrained side effects. By expressing more func- 
tional properties and constraints in interfaces than what is 
usual in object-oriented languages, we describe components 
in such a way that they can be integrated and re-integrated 
in a dynamic, flexible fashion. Many API changes and mu- 
tations should be compensated for automatically as they oc- 
cur. We believe that the integration approach presented here 
could be an important step towards much greater reusability 
and ease of maintenance in component-based development. 

As for future work, most importantly, we aim to provide a 
practical implementation and investigate how Poplar works 
in practice. We also expect to need to investigate more so- 
phisticated aliasing policies, exception handling, effect sys- 
tems and concurrency support. It is interesting to note that 
the aliasing policy and the code generation mechanism mu- 
tually influence each other: since we do not generate all 
valid forms of Java code, but only statements with restricted 
forms, the alias analysis does not need to deal with all possi- 
ble cases. On the other hand, the more powerful the analysis 
is, the more freely code may be generated without having 
adverse effects. 

An essential limitation in the design presented here is the 
protection spans. By design, they assume that regions that 
need to be protected are continuous and part of the same 
method body. However, in practice, effects are often created 
and destroyed in quite separate locations of programs. Inves- 
tigating support for this is in the scope of future work. 
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